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CLIENT-SERVER DATA COMMUNICATION SYSTEM AND METHOD FOR 
DATA TRANSFER BETWEEN A SERVER AND DIFFERENT CLIENTS 



This invention relates to the field of data communications and in particular to a 
5 system and method for providing client independent data transfer between a server 
and different clients over a network and in which client differences such as small 
screens, limited keyboard, low bandwidth connection, data formats and small 
memory are easily accommodated for by the server. 

10 BACKGROUND OF THE INVENTION 

The rapid growth of the Internet and more specifically the World Wide Web 
(WWW or Web) as a network for the delivery of applications and content, has 
resulted in software developers quickly beginning to shift their focus towards 
15 making the web browser a key tool to access information. This revolution has 
taken several stages. 

Most information is available as static content, composed of a variety of media, 
such as text, images, audio, and video, that is described using hypertext markup 

20 language (HTML). While the WWW revolution has placed a wealth of 
information at the fingertips of countless people, and while HTML is a very good 
way of describing static documents, HTML provides no mechanism for 
interacting with Web pages. At present, a Web browser uses the Hypertext 
Transport Protocol (HTTP) to request an HTML file from a Web server for the 

25 rapid and efficient delivery of HTML documents. A. Web browser is a client 
process (also called a "client") running on a local or client computer that enables a 
user to view HTML documents. An example of a Web browser is the Internet 
Explorer. A Web server is a server process (also called a "server") running on a 
remote or server computer that uses HTTP to serve up HTML documents and any 

30 associated files and scripts when requested by a client. To accomplish this, the 
user gives the Web browser a Uniform Resource Locator (URL) for an object on 
the Internet, for example, a data file containing information of interest. The 
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document is referred to as a "Web page," and the information contained in the 
Web page is called content. Web pages often refer to other Web pages using 
"hypertext link" or "hyperlinks" that include words or phrases representing the 
other pages in a form that gives the browser the URL for the corresponding Web 
5 page when a user selects a hyperlink. 

Dynamic information retrieval such as selected information retrieved from 
databases commonly implemented through the use of the Common Gateway 
Interface (CGI). CGI is a common way for interfacing external applications with 

10 HTTP or Web servers in which a client, executing a CGI script embedded in an 
HTML page, sends a request to the Web server to execute a CGI program. The 
CGI script transfers environment variables comprising a query string and a path 
information parameter. The query string is a string of text to be searched for in the 
Web server's database For example, in a specific implementation of CGI the path 

15 information parameter is used to indicate the location of a file to be searched. 
While CGI allows specifically requested information to be accessed from 
databases across the Internet, CGI has very limited capabilities. Queries 
performed by CGI programs may amount to string matching in a data file, and the 
results returned to the Web browser are simply preformatted text or an HTML 

20 document listing the results In general, CGI can run an arbitrary executable or 
script that can return an arbitrary document given the querystring or post 
parameters. In general the key technology innovation was the ability for web 
pages to execute applications through the Common Gateway Interface (CGI) or 
through dynamic link libraries (e.g. the Internet Server Application Programming 

25 Interface (ISAPI) from Microsoft or Netscape's equivalent or Java servlets). 

An alternative to using separate CGI scripts to define content is a template-based 
HTML that actually embeds a request for the dynamic data within the HTML file 
itself When a specific page is requested, a pre-processor scans the file for 
30 proprietary tags that are then translated into final HTML based on the request. The 
final HTML is then passed back to the server and on to the browser for the user to 
view on their computer terminal. While the examples given have been explained 
in the context of HTML. Templates may be created with any Standard 
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Generalized Markup Language (SGML) based markup language, such as 
Handheld Device Markup language (HDML). In fact templates can be created 
with any markup language or text, in fact it is not limited to SGML based 
languages but rather to MIME types HDML, is a markup language designed and 
5 developed by AT&T and Unwired Planet, Inc. to allow handheld devices, such as 
phones, access to the resources of the Internet. The specifics of the language are 
disclosed in "HDML Language Reference, Version 1.0," Unwired Planet, Inc., Jul. 
1 996, and herein incorporated by reference Templates with the markup in it and 
some scripting to execute the data and the display of the pages are separated to 

10 make generating an application a process of using an HTML template with script 
embedded to generate the resulting page. Examples of this technology are Active 
Server Pages (ASP) from Microsoft, PHP from the Apache organization or Java 
Server Pages (JSP) from Sun. Often these have been developed in a three-tier 
physical and/or logical implementation in an attempt to separate the display from 

15 the data logic. 

As the HTTP based technology has matured, these have tended to move towards 
the clear separation of the HTML template from the underlying data. Recently 
there have been several other key advancements. 

20 

A subset and simplification of SGML, the extensible Markup Language (XML) 
has evolved as a standard meta-data format in order to simplify the exchange of 
data. The extensible Stylesheet Language (XSL) has evolved as the standard way 
to define stylesheets that accept XML as input; and Non-HTML browsers 
25 accessing data over HTTP are becoming common and in the next few years will 
become more common than browsers on desktop computers. 

One example is the Handheld Device Markup Language (HDML) from 
Phone.com and its evolution the Wireless Markup Language (WML) from the 
30 WAP Forum. The wireless networks around the world are converging to the 
Internet to support this trend. Universal Resource Locators (URL) now point to 
anything on the Internet and can be used by devices ranging from Mobile Phones 
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to Integrated Voice Response (IVR) servers using VoiceXML or VoXML 
(www.voxml.com). 



The presence of the Web has become international to the point that although 
5 North America is the leading market, it is not the only market to target 
applications and services. Furthermore there is a movement by international 
companies towards external hosting of applications that may access the data in a 
distributed manner across the Internet. This requires remote execution of data. 
The implementation of Unicode as part of XML and XSL standard is one of the 
10 reasons for allowing applications to be made international. That is why 
developers are able to internationalize applications with separate stylesheets. 

These above advancements in the market have strained the previous technology to 
a point where developers are incapable of rapidly delivering applications that can 
1 5 target the diverse browsers and devices as well as the target languages. 

While computer terminals and other devices that are configured to receive HTTP 
and HTML files may utilize the above methods to access and view the Internet 
data, the specific display standards for non-pc based browser devices such as 
20 PDA's, telephones, cell phones, television set-top boxes and similar devices, as 
well as the display capabilities for these devices allow only a limited view of 
HTTP transferred HTML files. In addition, these device display characteristics do 
not permit a user to take advantage of the hypertext features imbedded in most 
HTML data files. 

25 

At present there are two solutions to this problem. The first is the automatic 
transformation of pages to the appropriate device. This has proven to be 
ineffective in producing user interfaces since they need to be built to take 
advantage of the devices capabilities and to work within its limitations. 

30 

The second is the use of an XSL stylesheet with a XML URL source for the data. 
However, this solution does not take into account the need to target multiple 
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devices, and multiple languages. Also, these solutions have focused on bringing 
in XML data from a single XML URL source whereas in reality an application 
will need to bring in multiple sources and access non-URL data 

5 Clearly, as more content publishers and commercial interests deliver rich 

data in XML, the need for presentation technology increases in both scale 
and functionality. XSL meets the more complex, structural formatting 
demands that XML document authors have. On the other hand XSL 
Transformations known as XSLT makes it possible for one XML 

1 0 document to be transformed into another according to an XSL Style sheet. 

More generally however, XSLT can turn XML into anything textual, 
regardless of how well-formed it is, for HTML. As part of the document 
transformation, XSLT uses Xpath (XML Path language) to address parts 
of an XML document that an author wishes to transform. XPath is also 

15 used by another XML technology, XPointer, to specify locations in an 

XML document. 

However XSLT has also not addressed the problem of allowing the development 

applications that are easily decomposed, portable and easily distributed, while still. 
20 efficiently serving a multitude of different devices. Applications are generally 

comprised of a plurality of forms, which are connected to achieve a desired flow. 

It is desirable to allow developers the ability to reuse parts of application, however 

with the current markup language technologies it is difficult to achieve this. 

without recreating parts if not substantially all of the application. This problem is 
25 further compounded with the need to accommodate different device. At present 

stylesheets are still tightly linked to the flow of an application. 

Thus there is a need to for a tool easily develop and serve applications for these 
multiple devices. 

30 

Accordingly the present invention seeks to mitigate at least some of the above 
disadvantages. 
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5 SUMMARY OF THE INVENTION 



An advantage of the present invention is derived from the observation that data is 
separated from a stylesheet and from program flow. The separation of the flow 
and form meta-data is a requirement to break out the data from the stylesheets. 
1 0 Otherwise, the stylesheet must maintain maps of where it receives its data from as 
well as the relationships to different forms. The invention solves this problem by 
the creation of a schema, which provides all of the flow and meta information in 
an external file. 



In accordance with this invention there is provided a method of deploying a web- 
based application on a network comprising the steps of: 

(a) generating a data structure representing a set of forms and associated flow for 
the application; 

(b) associating with the application a plurality of style documents, ones of the 
documents being tailored to different client characteristics; 

(c) providing to the server a processor for processing the application; 

(d) in response to a request for a form from a client to the server, the processor 
accessing a set of data sources for the requested form defined in the 
application and aggregating the data into a single generated data document, 
the processor executing a style processor for processing the generated data 
document and a selected style sheet corresponding to the client characteristics 
to generated the requested form for the client; and 

(e) forwarding the form processed at the server to the client. 
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BRIEF DESCRIPTION OF DRAWINGS 

Embodiments of the invention will now be described by way of example only, 
with reference to the accompanying drawings in which: 

5 

Figure 1 is a block diagram depicting a wireless network system; 

Figure 2 is a block diagram depicting the major components in a system according 

to an embodiment of the present invention; 

Figure 3 is a schematic diagram of the application element structure in a Hosted 
1 0 Markup Language application; 

Figure 4 is a schematic representation of the form element structure in the Hosted 
Markup Language; 

Figure 5 is a schematic representation showing the structure of the Runtime 
Markup Language; 

15 Figure 6 is a block diagram of the high level components for processing of HML 
to generate RML; 

Figure 7 is a block diagram showing the flow for the execution of components 
described in Figure 6; 

Figure 8(a) is a schematic diagram of a Bank account query application; 
20 Figures 8(b)-(d) is a schematic representation of an HML file for the Bank 
account query application; 

Figures 9(a), (b) and (c) are mark-up language representations of a sample 
generated RML for the Bank account query application; 

Figures 10(a) and (b) are mark-up language representations of an XSL style sheet 
25 for the Bank account query application; and 

Figure 1 1 is a mark-up language representation of a WML document returned to a 
device in the Bank account query application. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

30 

In the following description, the same reference numerals will be used in the 
drawings to refer to the same or like parts. 
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Referring to figure 1, a block diagram of a data communication system in which 
the present invention may be used is shown generally by numeral 100. The 
present invention is described in the context of the Internet, wherein client devices 
5 102 make requests, through a portal or gateway 104, over the Internet 106 to web 
servers 108. Web servers 108 are capable of communicating via HTTP, HTTP/S 
or similar and providing information formatted with HTML codes the client 102 
which may be capable of interpreting such codes or may rely on a translation by 
the portal 106. In this embodiment, HTML is described as one example and the 

10 gateway may or may not translate. In fact, a gateway is not necessary for the 
majority of connecting devices. In a particular instance, the client 102 may be a 
cell phone device 1 10 having a screen display 1 12, the portal 106 may be a cell 
phone network 114 that routes calls and data transfers from the telephone .1 10 to a 
PSTN or to other cellular phone networks. The cell phone network 114 is also 

15 capable of routing data transfers between the telephone 110 and the Internet 106. 
The communication between the cell phone network 114 and the Internet 106 is 
via the HTTP protocol, or WAP which is more likely for a phone network, the 
gateways typically translate the call to HTTP, which is well known in the art. 
Furthermore, it is assumed that the telephone 110 and the cell .phone, network 

20 implement the appropriate protocols for a web browser or similar that can retrieve 
data over the internet and translate the data file for display on the display 112. 
The system 100 also includes at least one host server or web server, which is a 
remote computer system 112 which is accessible over the internet to the cell 
phone network and the telephone 1 02. 

25 

The web server 108 includes data files written in a mark up language, which may 
be specifically formatted for the screen display 104 of the telephone 102. This 
language could comprise a standard text based language similar to HTML or 
could include WML, HDML, or other specifically designed mark up language or 
30 simply text to send to a phone. 
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The web server 108 may also include an application which is run on the server 
and is accessible by the device 1 10 specifying a URL or similar of the application. 
At present, the system 100 operates by the device 1 10 transmitting a request to the 
cell phone network 1 14. The cell phone network 114 translates the request and 
5 generates a corresponding HTTP formatted message, which includes the requested 
URL. The HTTP request message is transmitted to the web server 108 where a 
data file is located. The data file must be formatted to be compatible to the 
display capabilities of the telephone 102. The web server calls a process, which 
invokes an XSL stylesheet interpreter with the appropriate HML and the 
10 stylesheet to create the formatted markup of the appropriate MIME type. In some 
cases both the XML input and the XSL stylesheet may be provided to the client 
browser to interpret if the client has an XSL built. 

By way of background, Extensible Markup Language, abbreviated XML, 
15 describes a class of data objects called dt-xml-doc XML documents and partially 
describes the behavior of computer programs which process them. XML is an 
application profile or restricted form of SGML, the Standard Generalized Markup 
Language. By construction, XML documents are conforming SGML documents. 

20 XML documents are made up of storage units called entities, which contain either 
parsed or unparsed data. Parsed data is made up of characters some of which form 
character data dt-chardata . and some of which form markup. Markup encodes a 
description of the document's storage layout and logical structure. XML provides 
a mechanism to impose constraints on the storage layout and logical structure. 

25 

A software module called an XML processor is used to read XML documents 
and provide access to their content and structure. It is assumed that an XML 
processor is doing its work on behalf of another module, called the application, 
which resides on the web server 108. 

30 

Each XML document has both a logical and a physical structure. Physically, the 
document is composed of the units called entities. An entity may refer to other 
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entities to cause their inclusion in the document. A document begins in a "root" or 
document entity. Logically, the document is composed of declarations, elements, 
comments, character references, and processing instructions, all of which are 
indicated in the document by explicit markup. The logical and physical structures 
5 must nest properly. 

Each XML Document contains one or more elements, the boundaries of which 
are either delimited by start-tags and end-tags. Each element has a type, identified 
by name, sometimes called its "generic identifier" (GI), and may have a set of 
1 0 attribute specifications. Each attribute specification has a name and a value. 

Style Sheets can be associated with an XML Document by using a processing 
instruction whose target is xml-stylesheet. This processing instruction follows the 
behavior of the HTML 4.. The xml-stylesheet processing instruction is parsed in 
1 5 the same way as a start-tag, with the exception that entities other than predefined 
entities must not be referenced. 

XSL is a language for expressing stylesheets. A stylesheet contains a set of 
template rules. A template rule has two parts: a pattern, which is matched against 
20 nodes in the source tree and a template, which can be instantiated to form part of 
the result tree. This allows a stylesheet to be applicable to a wide class of 
documents that have similar source tree structures. 

Each stylesheet describes rules for presenting a class of XML source documents. 

25 An XSL stylesheet processor accepts a document or data in XML and an XSL 
stylesheet and produces the presentation of that XML source content as intended 
by the stylesheet. There are two sub-processes to this presentation process: first, 
constructing a result tree from the XML source tree and second, interpreting the 
result tree to produce a formatted presentation on a display, on paper, in speech or 

30 onto other media. The first (sub-)process is called tree transformation and the 
second (sub-)process is called formatting. The process of formatting is performed 
by the formatter. 
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As described above, the prior art technique is tedious and not easily adaptable to 
different devices and applications and a plurality of user languages.. One 
embodiment of the present invention is thus based on the observation that a 
5 solution to the above problem is a separation of data from style sheets which in 
turn is separated from program flow. Although it has been recognized that the 
characteristics of a display needs to be separated from the data, in practice current 
solutions have failed to understand that the separation of the flow and form 
metadata is necessary before data can be separated from the style sheets. In other 
10 words, at present, style sheets must maintain maps of its data sources and its 
relationships to different forms. Accordingly, the present invention solves this 
. problem by providing a hosted mark up language (HML) for providing flow and 
meta information in an external file. 

15 Thus turning to figure 2, there is shown at numeral 200, the general components 
of a system, according to an embodiment of the present invention, for providing a 
unified data transfer between different devices (clients) and a server over an 
HTTP based network. The system 200 includes a hosted mark up language (HML) 
file or application 202 written in accordance with the present invention and 

20 residing on the web server 108, a plurality of style sheets 210 and a run-time 
program or processor 204 for processing the HML application 202 in response to 
an HTTP message corresponding to a request received from the client device 110. 
The HML application 202 includes a plurality of forms and pointers to external 
data sources. The processor 204 includes a data server 206 for retrieving data 

25 from one or more databases 216, 218 in accordance with the instructions in the 
HML, an XSL processor 208, and the plurality of XSL style sheets 210. 

A further embodiment of the system 200 includes a visual authoring tool 220 for 
providing a development framework for visually connecting forms defining a 
30 look, feel and flow of an application and for generating from the visual layout the 
HML application 202. 
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In general, the runtime 204 is called by a device 102 in a manner as described 
with reference to figure 1, which connects to the server 112 using HTTP. Based 
on the URL that is requested and the type of device making the request, the 
runtime 204 determines an appropriate form to use. The runtime calls a data 
5 server component 206 to obtain data for the URL from one or more databases 118 
and 116. The data server 206 retrieves the appropriate data into XML, and 
forwards this to the runtime which in rum adds runtime information and directory 
information to the data XML, the data structure that is built or populated by the 
HML processor is termed RML, the structure of which will be described with 

10 reference to figure 5 later.. The runtime calls the XSL processor 208 with the 
RML and an appropriate style sheet 210 for the form after the runtime 204 calls 
the XSL processor 208, the XSL processor generates a file that depends on how 
the XSL stylesheet was written. In particular a stylesheet is written for a 
particular MIME content-type.(notice that in the description of the RML 

15 stylesheet we have a content-type attribute) For example if it is HTML with 
embedded XSL instructions then the processor will generate HTML, if it is a 
simple test file with embedded XSL instructions then simple text will be 
generated. Thus if the requesting device has a specific mark-up, the runtime 204 
returns the appropriate mark-up file. However, if the device does not have the 

20 specific mark-up, the run time transforms the generated WML to the appropriate 
markup and sends it back to the device. 

The detailed description of the operation and interconnection of the various 
components will be described in greater detail in the following paragraphs. 

25 

Referring to figure 3, there is shown at numeral 300 a defined schema or data 
structure for the elements contained in an HML application. All of the elements 
are described as XML based schemas including attributes and elements. The first 
element of the HML 300 is an 
30 Application Element 301 which is a root element having Key Attributes: 
"id" which is a unique identifier for the application; 
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"language" which describes which variable to extract the user language 

from. 

Children Elements: 

Startform 307, containing an id attribute which points to a Form's targetid 
5 within the application; 

forms collection 302 having Multiple Form elements; 
Multiple Connection elements 303; 

A Data element contained within an events element which contains 
multiple component elements 309; 
10 Multiple Directory elements 308 containing information to connect to 

directory type data. Contain a name attribute. 
Connection Element 303 

Defines a connection to an outside source of data. 
Key Attributes: 

1 5 "connectionid" which is a unique identifier for the connection; 

"type" which determines how to get the data; 
"server" which gives the IP address to access the server; 
Children Elements: 
Authenticate 304 

20 Schema element 305 containing a URL attribute to access the schema 

information; 

Multiple connectionproperty elements 306 providing name/value pairs as 
inputs to the component defined by the "type" attribute. 

Component Element 3 1 1 
25 Defines an external set of data. Since this is underneath the application it will be 

passed to all forms. 

Key Attributes: 

"connectionid" points to a connection element 303; 

Authenticate Element 304 defines how to authenticate against an external 
30 data source; 

Key Attributes: 

"user" provides the usemame for authentication; 
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"password" provides the external password; 

The text of the authenticate element can contact CData or any other 
information that is used by the data server 206 to authenticate. Examples 
include certificates, etc. 
5 Form Element 302 which is shown in detail in figure 4 generally by numeral 400 

This, element defines a form and is contained under the forms collection of the 
application. 

Key Attributes: 

1 0 "targetid" which is a unique identifier for the form 

"language" which describes which variable to extract the user language 

from. 

Children Elements: 

Multiple Stylesheet 415 elements 
15 Multiple action 412, input variables 413, and output variables 414 

which define the flow and application reuse. 

A Data element 422 ontained within an events element 420 which 

contains multiple Component elements 41 1; 
Stylesheet Element 415 
20 Defines a potentially matched stylesheet for a form 

Key Attributes: 

"URL" defines an external link to the actual XSL stylesheet file 
210 or instead of having an external XSL file 210, the text of the 
stylesheet element can contain an embedded CData containing the 
25 stylesheet contents;. 

"contenttype" determines the MIME type of the generated XSL 
stylesheet file. Examples include "text/xml", "text/plain", and 
"text/html". 
Children Elements: 

30 Multiple Device elements 416. The device only has a single 

attribute "name"; 
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Multiple Language elements 41 7. The language element only has a 
single attribute "language"; 
Component Element 41 1 

Defines an external set of data. Since this is underneath the form 302 it will only 
5 be passed into stylesheets on this form, otherwise it is identical to the application 
level component element 309; 
Key Attributes: 

"connectionid" points to a connection element 303 

10 As described earlier the runtime processor processes the HML and creates and 
populates a resulting RML data structure. Referring to figure 5, the data structure 
or schema of the RML according to an embodiment of the invention is shown 
generally at numeral 500. The RML schema is comprised of: 
RML element 528 — the root element; 
15 Children Elements: 

Session element 529, Appconstants 530, and Actions defining flow 532 
Multiple variable elements 53 1 underneath the variables collection. These 
just have a name attribute and the text of which contains the value. 
Multiple directory element 533 containing data from directory connections 
20 308 

Multiple data elements 537 containing data from data connections 303. 
Session Element 529 contains information from the user request. 
Key Attributes: 

"appid" points to the id attribute of the Application element 307; 
25 "fromformid" points to the targetid attribute of a form element 302; 

"actionid" is the name of the action 412 defined on the form 402 and is 
used for flow; 

"deviceid" stores the name of the device 110 and links to a value in a 
device lookup table 553 described later with reference to figure 7; 
30 Directory Element 533 is a container for the data from a directory connection. 

Primary difference between this and the Data element 537 is that the directory 

connections always have a consistent hierarchical schema. 
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Key Attributes: 

"name" uniquely identifies the directory input. It will be the name 
attribute from one of the Directory elements in the application 308. 
Children Elements: 

5 Contains multiple Item elements 534, which in turn can have its own item 

elements and attribute elements 535. This defines an arbitrarily deep 
hierarchy of directory/profiling type data. 
Data Element 533 

The Data element is a container for the data from a data connection. The key is 
10 that it provides a way to store arbitrary XML document fragments within the 
RML. 

Key Attributes: 

"name" uniquely identifies the data. It will be the component id from one 
of the application 309 or form components 411. 
1 5 Children elements: 

It can contain any hierarchy and elements that is consistent with the 
schema defined in 305 for its components, connections, schema. 

Referring to figure 6, there is shown generally at numeral 600, a schematic 
20 diagram of the subcomponents of the runtime processor 204. The runtime 
processor 204 includes transport components 619, an executive 620, 
transformation components 621, and form components 623. The operation of the 
runtime processor 204 to generate the RML is now described by referring to 
figure 7, In the following description the term "set" refer to the process of setting 
25 or populating pieces of the RML document. The process is described by the 
sequence of blocks 738 to 748. Block 738 is the entry into the processing. 



At step 738, the transport component receives a call from the requesting device 
generated through some sort of URL. The transport component 619 processes the 
30 incoming HTTP request and extracts amongst others the following values, which 
are used to populate the appropriate sections of the RML structure 500. The 
values it extracts are: 
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The value of the "_SQAPPID" variable in query string/post/cookie is 

placed into the session element 529 "appid" attribute; 

The value of the " SQFORMID" variable in query string/post/cookie is 

placed into the session element 29 "fromformid" attribute; 
5 The value of the "_ACTIONID" variable in query string/post/cookie is 

placed into the session element 29 "actionid" attribute; and 
"_SQFORMID" variables on the query string are extracted as values and 
placed into the session element 29 "fromformid". 

10 The transport component 719 is also responsible for extracting and 

determining the "device" attribute within the session element 529. The 
query string may provide the device attribute directly as a variable called 
"device" which is directly placed into the "device" attribute of the session 
element 529 of the RML structure. If the device variable is not set, then a 

15 look-up table may be used to determine this value by using the 

"HTTP_User_Agent" header. A look-up table for determining the device, 
variable is shown below in Table I: 



Table I 



User Agent 


UASubstring 


Device 


Content 


UP.Browser/3.1-UPGl UP.Link/3.2 


UP. Browser 


UPBrowser 


text/hdml 


Mozilla/4.0 (compatible; MSIE 5.01; 


Mozilla 


HTMLDefault 


text/html 


Windows NT 5.0) 









20 While the UserAgent information is provided in every HTTP request, there is no 
consistency in the format of the strings between various browsers. Since the 
system needs to determine the type of the connecting device, a method is 
necessary to map the value in the string to a name for a device. 

25 The lookup table I can be stored directly in the HML file, in a database, or in a 
registry depending on the platform for implementation. The key is that it is easily 
editable and flexible. The first column in the table is not stored in the actual table 
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but represents real examples of connecting user agent strings for the UP 
Emulator's HDML browser and Microsoft's Internet Explorer HTML browser 
respectively. The user agent string is matched to rows in the lookup table 
attempting to do a UAsubstring search of column two within the incoming 
5 HTTPUSERAGENT column one. When a match is found, the matched device 
name from column three is placeed into the "device" attribute of the session 
element 529. If no match is found then a default text "HTMLDefault" is placed 
into the "device" attribute of the session element 529. 



10 At Step 739 which is similar to Step 738 the transport component 619 extracts 
variables form the HTTP headers and the query string/post/cookies. However, 
instead of filling in the Session element 529 it fills in the Variable elements 
underneath the variables element 531 including: 

All variables on the query string, post, or in cookies. For example, 
15 "http://myserver/transport.asp?varl=a&var2=b" would place two new 

input variables 31 with name attributes of "varl" and "var2" and values of 
"a" and "b". 

All Custom HTTP Headers. An example of a custom header from a 
UPXink gateway from Phone.com is: "HTTP_X._UP^SUBNO" and the 
20 value might be: "9 19799575-1 4655 l_up.mytelco.ca". This would add in a 

input variable 31 with a name attribute of "HTTP_X_UP_SUBNO" and a 
value of "919799575-146551_up.mytelco.ca". 

While the described implementation of the Transport 6 1 9 relies on data accessible 
25 from HTTP it is not necessary. As long as name/value pairs can be extracted from 
the incoming protocol the transport can fill in the appropriate RML elements. 
Similar variations include a Transport 619 designed to accept Simple Message 
Transport Protocol(SMTP) or Wireless Application Protocol(WAP) requests. 

30 In Step 740 the Executive 620 is called by the Transport 619. The Executive 620 
uses the "appid" attribute of the Session element 529 to create the application 
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component 622, shown in figure 6, based on a match with the "id" attribute of the 
Application element 301. 

In Step 741 the Application 622 uses the "fromformid" and the "actionid" of the 
5 Session element 529 to find the appropriate form object to create. It does this by 
looking up the form 302 within its application 301 and matching the "targetid" of 
the form to the "fromformid". It then looks at the action elements 412 within the 
particular form 410 to find the action whose "actionid" matches the "actionid" of 
the Session 529. From this action it can find the "targetid" of the form element 
1 0 302 within the application 301 . It uses this form identifer to create the appropriate 
form component 623, shown in figure 6. 

In Step 742 the Form component 623 traverses the sub-elements of the Form 410 
to set to Action 532 of the RML structure 500. 

15 

In Step 743 the form component 623 uses the directory connection information for. 
the application 301 defined in 308 to call the appropriate directory component 
624, shown in figure 6, and populate the directory RML contained in 533. The 
details of executing the directory components are described in a separate patent 
20 application. 

In Step 744 the Form 623 creates a SOAP based data server components 626 with 
information to create components to generate arbitrary XML data. The data 
server components 626 are called for each component in the application level 
25 component 309 and the form level components 11. It passes "connectionid" 
attribute for the data server component 626. 



In Step 45 the data server component 626 uses the "connectionid" attribute passed 
in to create and execute the appropriate components. The "type" attribute of the 
30 connection 303 is the name of the class which is the handler for this particular 
type of connection. Examples include "MQProvider.COM", "MQProvider.Java", 
"MQProvider.URL", and "MQProvider.ODBC". The data server component 
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creates 626 this class and passes in the complete RML tree 528, the authentication 
information 304, and all of the connection properties 306. The implementation of 
the created component uses all of these values to get data from the source defined 
by its components. 

5 

The implementation of these components from data server components 626 is 
intended to be as general as possible and the only assumption to the functionality 
of this plugin is that it takes values as defined in Step 745 and returns back XML 
data that can be validated by the schema 305 for the connection. The 
10 connectionproperty elements 306 are used internally to the component to define 
where and how the execution occurs. Example implementations include: 

The "MQProvider.COM" requires a connection property 306 called 
"progid". It uses the Microsoft COM library to create the object defined in 
"progid". It then calls a defined interface on the component and passes in 
15 the RML root 528 as an input. It directly takes the output of the 

component as XML to pass to the next step. 

The "MQProvider.URL" implementation might require a connection 
property 306 called "path". It uses the "server" attribute of the connection 
303^and this path to construct a complete URL. An example might be: 
20 "http://myserver/mypage.xml". It then uses internet functions to access 

this page over the web. The only assumption is that the page returns data 
in XML which it directly passes on to the next step. 

In Step 746 for each of the component "connectionid" attributes, the data server 
25 component 626 creates a data element 537 in the RML 500 and sets the "name" 
attribute is equal to the "connectionid" attribute. It then puts the XML data 
created in Step 745 as sub-elements underneath this data node. 

In Step 747 the Form components 623 uses the value in the "language" attribute of 
30 the application 301 to find the name of the variable to find the user's preferred 
language in. It does a lookup in the variables 531 and places the value into the 
"language" attribute of the session element 529. The rest of step 747 attempts to 
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match the appropriate stylesheet within the form based on the "device" 416 and 
"language" attributes 417 of the Session element 529. The matching process 
begins by enumerating the stylesheet elements 415 for the form 410 then the 
process continues as: 

5 Look for an exact match of "language" and "device" attributes in the 

session 529 to the "name" attributes of the language and device elements 
416 and 417 within each stylesheet 415; 

If no match is found then it changes the language to "default" and attempts 
the same matching; and 
10 If no match is found then it changes the device to "HTMLDefault" and 

attempts the same matching. This is guaranteed to have a match. 

In Step 748 the Form component 623 takes the stylesheet element 415 returned 
from the previous step and uses the URL attribute or the text within the element to 
15 get an actual XSL file. It then calls the XSL interpreter 208 with this file and the 
complete RML 528 as the input. The specific XSL interpreter does not need to be 
defined since all available interpreters generate some sort of file which represents 
the file to be sent back to the user. 

20 In Step 749 the Executive 620 decides if a transformation component 621 is 
required. It does this by looking at the "contenttype" (column four of table I) of 
the appropriate "device" (column three of Table I) and comparing it to the 
"contenttype" of the stylesheet 415. If the values are the same then no 
transformation is required. If they are different then it uses an internal table to 

25 determine which transformation component 621 to call. After calling the 
transformation the resulting form will definitely have the contenttype (column 
four of Table I) expected by the device (column one of Table I). 

In. Step 50 the Transport component 619 returns back the generated form to the 
30 device 110 while setting the "contenttype" of the returned file to be consistent 
with device column of Table I. 
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Referring now to figures 8, 9, 10 and 11, there is shown an application of the 
present invention to an English language WML enabled phone accessing a bank 
account query application. The application, which is specified in the HML code 
shown schematically in figures 8(a), is comprised of a sequence of forms 802 to 
5 818. The generated HML is shown in figure 8(b)-(d). 

Although the above described with respect to client-server, where client is a 
mobile device. The invention is equally applicable to a situation where a client 
does not have a browser such as in a business to business scenario. For example 

1 0 such as is executing an order from a supplier (server) to a customer (client). Both 
parties may be server computers wherein information is requested by a first server 
(client) from a second server. The second server (server) retrieves and formats the 
information for direct storage in the first server's database. The invention is also 
applicable to situations where the forms are not displayable. In a further 

1 5 embodiment the invention may be used in an Intranet. 

Although the invention has been described with reference to certain specific 
embodiments, various modifications thereof will be apparent to those skilled- in 
the art without departing from the spirit and scope of the invention as outlined in 
20 the claims appended hereto. 
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THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE 
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS: 

5 1 . A method of deploying a web-based application on a network comprising the 
steps of: 

(a) generating a data structure representing a flow and associated forms for 
the application; 

(b) associating with the application a plurality of style documents, ones of 
1 0 said documents being tailored to characteristics of different clients; 

(c) providing to said server a processor for processing said application; 

(d) in response to a request for a form from a client to the server, the 
processor accessing a set of data sources for the requested form defined in 
the application and aggregating the data into a single generated data 

15 document, the processor executing a style processor for processing the 

generated data document and a selected style document corresponding to 
the client characteristics to generate the requested form; and 

(e) forwarding the form processed at the server to the client. 

20 2. A method as defined in claim 1 , said generated data document being an XML 
document. 

3. A method as defined in claim 1, said style sheet is an XSL style sheet and said 
style processor is an XSL processor. 

25 

4. A method as defined in claim 1 , said form being a displayable form. 

5. A method as defined in claim 1, said client characteristics including a 
character display size Of said client. 

30 



6. A method as defined in claim 1, said client including a web server. 
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7. A system for deploying a web-based application on a network comprising: 

(a) at a server, a processor for processing said application, said application 
comprising a data structure representing a sequence of forms and an 

5 associated flow for the application; 

(b) a plurality of style documents associated with the application and ones of 
said documents being tailored to ones of a plurality of client 
characteristics; 

(c) at said server, a process for processing said application in response to a 
10 request for displayable form from a client to the server, the processor 

accessing a set of data sources for the requested form defined in the 
application and aggregating the data into a single generated data 
document; 

(d) a style processor for processing the generated data document and a 
15 selected style sheet corresponding to the client characteristics to generate 

the requested form for the client; and 

(e) a transmission processor for forwarding the form processed at the server to 
the client. 

20 8. A system as defined in claim 7, said generated data document being an XML 
document. 



9. A system as defined in claim 7, said style sheet being an XSL style sheet and 
said style processor is an XSL processor. 

25 

10. A system as defined in claim 7, said style documents being contained within 
said application. 

11. A system as defined in claim 7, said application including a pointer to said 
30 style documents. 



12. A system as defined in claim 7, said application including: 
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(a) root element for describing the structure and flow of a single application; 

(b) a form element describing a logical screen that is presented to a user on one of 
a plurality of clients; 

5 (c) a style sheet element defining a collection of style sheets for ones of said 
forms for rendering said form to a selected mark up; and 
(d) a connection element for defining a set of components to receive the data from 
a plurality of data sources. 
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<?xml version = "1.0" encoding = "UTF-8" ?> 
- opplication usecookies= "false" id=' ■CF6681A6F-FB7C-4901-a55C-0a791DDE8DC8}" 

secu reva ria b les = "f a I se" > 

^description version="l" name = "MQBanking" /> 
<outtargets /> 

<startform totargetid="UserID" /> 
<subapps /> 

<errortarget totargetid = "UserID" /> 

- <properties> 

<variable default="209.23.23.23" name="ServerIP" /> 
</properties> 

- <sessionvariables> 

<variable name="Session" /> 
</sessionvariables> 

- <forms> 

- <rbrm targetid="UserID" includeheaders="ffalse"> 

<stylesheet contenttype="WMLll" url=*'http://www.mobileq.com" /> 
<action totargetid=" Password" name="OK" /> 
<inputvariables /> 

- <outputvariables> 

<variable name="UserID" /> 
</outputvariables> 
<events /> 
</form> 

- <form targetid='"Password" includeheaders="false"> 

<stylesheet contenttype="WMLll" url="http://www.mobileq.com" /> 
octiort totargetid="Main" name="OK" /> 

- <inputvariables> 

<variable name="UserID" /> 
</inputvariables> 

- <outputvariables> 

<variable name="Session" /> 
</outputva riables> 
< events /> 
</form> 

- <farm targetid="Main" includeheaders="false"> 

<stylesheet contenttype="WMLll" url = "http://www.mobileq.com" /> 
<action totargetid = "Account" name= "Account Balance" /> 
<action totargetid="Bill Payment" name="Bill Payment" /> 
<action totargetid="Transfer" na me = "Account Transfer" /> 
<inputvariables /> 
<outputvariables /> 
<events/> 
</form> 

- cform targetid="Account" includeheaders="false"> 

<stylesheet contenttype="WMLll" url = "http://www.mobileq.com" /> 
<action totargetid="Details" name="OK" /> 
<inputvariables /> 

- <outputvariables> 

<variable name="AccountID" /> 
</outputvariables> 
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< events /> 
</form> 

- <form targetid="Details" includeheaders="false"> 

<stylesheet contenttype="WMLll" url= "http://www.rn bileq.com" •/> 
oction totargetid = "Main" name="OK" /> 

- <inputvariables> 

<variable name="AccountlD" /> 
</inputvariables> 
<outputvariables /> 
< events /> 
</form> 

- <form targetid="Bill Payment" includeheaders="false"> 

<stylesheet contenttype="WMLll" url="http://www. mobileq.com" /> 
oction totargetld="Bill" name="OK" /> 
<inputvariables /> 

- <outputvariables> 

<variable name="AccountID" /> 
</outputvariables> 
< events /> 
</form> 

- <form targetid="Bill" includeheaders="false"> 

<stylesheet contenttype="WMLll" url="http://www. mobileq.com" /> 
oction totargetid="Amount" name="OK" /> 

- <inputvariables> 

<variable name="AccountID" /> 
</inputvariables> 

- <outputvariables> 

<variable name = "BiMID" /> 

<variable name="AccountID" /> 
</outputvariables> 
< events /> 
</form> 

- <form targetid="Amount" includeheaders="false"> 

<stylesheet contenttype="WMLll" url="http://www. mobileq.com" /> 
oction totargetid = "Confirm" name="OK" /> 

- <inputvariables> 

<variable name="BIIIID" /> 
<variable name="AccountID" />. 
</inputvariables> 

- <outputvariables> 

<variable name="AccountID" /> 

<variable name="BillID" /> 

<variable name="Amount" /> 
</outputvariables> 
<events /> 
</form> 

- <form targetid="Confirm" includeheaders="false"> 

<stylesheet contenttype="WMLll" url="http://www.mobileq.com" /> 
oction totargetid = "Main" name="Cancel" /> 

- <inputvarlables> 

<variable name="AccountID" /> 



•cvariable name = "BillID" /> 
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< variable name=' Amount" /> 
</inputvariables> 
- <outputvariables> 

< variable name="AccountID" /> 
<variable name= "BilllD" /> 
<variable name= "Amount" /> 
</outputvariables> 
< events /> 
</form> 
</forms> 
<errors /> 
<events /> 
</application> 



P>5 ted) 
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- <rml> 
- <dataresults> 
- <data name="sourcel"> 
- <RECORDS> 

- <RECORD> 

<Blair PK="l n >172-32-1176</Blair> 
<Testl PK="1">1</Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>White</LastName> 
<FirstName>Johnson</FirstName> 
</RECORD> 

- < RECORD > 

<Blair PK="l">213-46-89K/Blair> 
<Testl PK="1">K/Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Green</LastName> 
<FirstName> Marjorie</FirstNarne> 
</RECORD> 

- <RECORD> 

<Blair PK="l">238-95-7766</Blair> 
<Testl PK="1">1</Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Carson</LastName> 
<FirstName>Cheryl</FirstName> 
</RECORD> 

- <a> 

- <RECORD> 

<Blair PK="l">238-95-7766</Blair> 
<Testl PK="1">1</Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Carson</LastName> 
<FirstName>Cheryl</FirstName> 
</RECORD> 
</a> 

- <a> 

- <b> 

- <RECORD> 

<Blair PK= "l">238-95-7766</Blair> 
<Testl PK="1">1</Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Carson</LastName> 
<FirstName>Cheryl</FirstName> 
</RECORD> 



</b> 
</a> 
</RECORDS> 
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</data> 
- <data name="s urce2"> 
- < RECORDS > 

- <RECORD> 

<Blair PK="l">aaaaaa</Blair> 
<Testl PK="1">K/Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>White</LastName> 
<FirstName>Johnson</FirstName> 
</RECORD> 

- <RECORD> 

<Blair PK="l">bbbbbbb</Blair> 
<Testl PK="1">K/Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Green</LastName> 
<FirstName>Manorie</FirstName> 
</RECORD> 

- <RECORD> 

<Blair PK="l">cccccc</Blair> 
<Testl PK="1">1</Testl> 
<Test2 PK=°1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Carson</LastName> 
<FirstName>Cheryl</FirstName> 
</RECORD> 

- <a> 

- <RECORD> 

<Blair PK="l">ddddddd</Blair> 
<TfesMM(3k5!=M^>*.</Tesftl > 
<Test2 PK="1*'>2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Carson</LastName> 
<FirstName>Cheryl</FirstName> 
</RECORD> 

</a> 

- <a> 

. <b> 

- <RECORD> 

<Blair PK="l'">eeeeeeee</Blair> 
<Testl PK="1">1</Testl> 
<Test2 PK="1">2</Test2> 
<Test3 PK="1">3</Test3> 
<LastName>Carson</LastName> 
<FirstName>Cheryl</FirstName> 
</RECORD> 
</b> 
</a> 
</RECORDS> 
</data> 
</dataresults> 
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<actions> 

oction formatstring= "" actionid = "OK" querystring = "? 
_SQRSIGN=A&_SQAPPID={B77444Al-BD9E-4248-A664- 
6C483F8B4540}&_ACTIONID=OK8»_SQFORMID={8D7B4336-6341- 
4D2C-B2D8-49FE88DlB13A}8rEmployeeID=$EmployeeID" /> 

</actions> 
- <dictionary> 

<variable /> 

<variable /> 
</dictionary> 



</rml> 
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<xsl: stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> 
- <xsl: template match="/"> 
- <wml> 

- <head> 

<meta name="FormType" content="SQS6lectForm" /> 
•cmeta name="LlstMethod" content ="numeric" /> 

</head> 

- <card> 

<xsl: attribute name="title">qwe</xsl:attribute> 

- <p> 

- <select> 

<xsl: attribute name="title ">qwe</xsl:attribute> 
<xsl: attribute name="name">asd</xsl:attribute> 

- <xsl:for-each select="/rntl/dataresults/data 

[@name='source2']//RECORD"> 

- <option> 

- <xsl: attribute name="value"> 

<xsl:value-of select="Blair" /> 
zlz 

<xsl:value-of select="Testl" /> 
zlz 

<xsl:value-of select="Test2" /> 
zlz 

<xsl:value-of select="Test3"./> 
</xsl:attribute> 

- <xsl: attribute name="title"> 

<xsl :value-of select="LastName" /> 
i 

<xsl:value-of select="FirstName" /> 

oEslfvalue-of select=V rml/data * 
[©names'sourcel'l/RECORDS/RECORD/Blair" /> 

</xsl:attribute> 
blah blah blah 

</option> 
</xsl:for-each> 
</select> 
</P> 

- <xsl:for-each select="/rml/actions//action"> 

- <do> 

<xsl attribute name = "type">accept</xsl:attribute> 

- <xsl:attribute name = "label"> 

<xsl:value-of select="@actionid" /> 
</xsl:attribute> 

- <go> 

- <xsl:attribute name="href"> 

<xsl:value-of select="@querystring" /> 
</xsl : attribute > 
</go> 
</do> 
</xsl:for-each> 
</card> 
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</wml> 
</xsl:template> 
</xsl : stylesheet> 
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- <wml> 



- <head> 

<meta name="FormType" content = "SQSelectF rm" /> 
<meta name="ListMethod" content="numeric" /> 
</head> 

- <card title = "Select Account"> 

- <p> 

- <select title="Select Account" name = "HoldingsAccountID"> 
<option value="l" title="Acct 10314">Acct 10314</option> 
<option value="2" title="Acct 11345" >Acct H345</option> 
</select> 
<br /> 
</p> 

- <do type="accept" label="OK"> 

<go href="?_SQRSIGN=A8i_SQAPPID={8D360BDF-E570-45E9-BECl- 
4E5DD$49C5C0>8i_ACTIONID=OK&_SQFORMID = -tBCC091Al-63D4- 
11D3-9E34-0090273EFC3B} 
&HoldingsAccoiintID=$(HoldingsAccountID) 
&UserID=246531&Session = l" /> 



</do> 
</card> 
</wml> 
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